The use of data encryption to prevent unauthorized disclosure of data stored on a storage medium is a widely used control, applicable, for example, from mobile devices through to the Internet of Things and high-end servers. Two standard data encryption approaches include full disk encryption (FDE) and file-level encryption (FLE). Full-disk encryption encrypts an entire disk (or partition, or logical unit number (LUN)) using a single key. Variants exist which provide key splitting and/or certificate-based access, although such variants nonetheless result in the production of a single key which decrypts the on-disk content.
FLE includes encrypting individual files on a disk. Each file may have its own key, or each entity (for example, a specific user) may have its own key, and some parts of a disk may even remain unencrypted (a concept also referred to as “folder encryption”). Key derivation is typically used so that key reuse across multiple files does not present the possibility of cryptanalytic attacks, and each file has its own unique key. FLE allows for protection of data from entities (users, processes, etc.) even on the same system, for which FDE does not protect.
FDE typically protects against inappropriate access to a given storage device. However, users and processes on a validly authorized system must rely on the operating system's (OS's) own controls, as entities on the system see the disk as plaintext. On the other hand, FDE can be carried out in hardware and/or device drivers. Both FDE and FLE require a reliable root of trust, thereby ensuring that the code associated with the cryptographic functionality has not been compromised.
In contrast to FDE, an FLE's threat model typically includes entities on the same system, potentially including even users with administrative access to the system. Protection against administrative users is difficult, however, because those administrative users may be able to access keys in memory. FLE can facilitate more complex access controls than FDE, even extending the base controls in the underlying OS. However, the implementation of FLE typically requires OS changes at the file (or filesystem) level, either implementing an entirely new encrypted file or fitting into an existing file. As such, the need to integrate the existing OS's identity management system to the key access control system can add significant complexity.
Key management presents challenges with both FDE and FLE. Keys are exposed to risk vectors that include storage and use. Accordingly, attempts are made to store keys securely, protected from all but authorized access. However, existing FDE and FLE approaches face challenges in protecting access to keys during use. For example, a key used in FDE and a key used in FLE are loaded into the given system's memory. There, the key is protected only by the OS's isolation techniques, where a malicious system process or administrator could access the keys. Research has shown that in-memory keys are easy to identify because such keys have very high entropy compared to other non-key memory contents. Ideally, keys should be resident in memory for as short a time as possible to minimize the possibility of attack.
Potential problems and vulnerabilities exist with such approaches. For example, such an approach can create vulnerability to a cold-boot attack, wherein the running memory of the system is accessed. Additional vulnerability can include potential key leakage via side-channel attacks (with respect to other processes on the system and/or other virtual machines (VMs) co-resident on a hypervisor). Further, another potential vulnerability exists via access to the key from malicious processes with administrative privileges (such as a rogue administrator, for example).
Accordingly, once access to the key to a disk, partition, and/or LUN is attained, full access to the data contained therein is possible. As such, a need exists for improved key management in connection with FDE and FLE.